Run oadp-operator e2e against kdm-controller/kdm-plugin PRs (oadp-dev, oadp-1.6) - #83049

Summary

Adds real oadp-operator e2e coverage for migtools/kubevirt-datamover-controller and migtools/kubevirt-datamover-plugin, on both oadp-dev and oadp-1.6, per openshift/oadp-operator#1832 (Group A2: operator-reconciled controllers gated on a DPA feature flag). Each repo's presubmit installs oadp-operator directly from its promoted bundle image via operator-sdk run bundle, substitutes the PR-built controller/plugin image into the running operator, and runs oadp-operator's own e2e suite — including the KubeVirt VM backup/restore specs already in that suite (e.g. openshift/oadp-operator#2350).

This depends on openshift/release#83110 (merged), which first added the promoted oadp-operator-index/oadp-operator-e2e-tests images. This PR replaces the index half of that with a promoted bundle instead — see "Why not an index" below for why the original index-based design didn't actually work.

Design

openshift/oadp-operator (base config for each branch)

operator.bundles[].skip_building_index: true (as: oadp-operator-bundle) builds and promotes just the bundle image (oadp-operator-bundle), no index/catalog at all — see rationale below. oadp-operator-e2e-tests (the e2e test binary) is unchanged.

migtools/kubevirt-datamover-controller + kubevirt-datamover-plugin (oadp-dev and oadp-1.6)

e2e-test-aws presubmit per branch (run_if_changed, not always-on):

1. ipi-aws-pre → optional-operators-operator-sdk-non-ci-bundle-image installs oadp-operator directly from the promoted bundle (OO_BUNDLE: registry.ci.openshift.org/konveyor/oadp-operator-bundle:{oadp-dev,oadp-1.6}) via operator-sdk run bundle — no index/CatalogSource image involved. (operator-sdk still creates a CatalogSource/OperatorGroup/Subscription under the hood — it just serves the catalog from a bundle-backed pod it manages itself, in openshift-adp, rather than pointing at a pre-built index image. The prior index-based design's CatalogSource also lived in openshift-adp, so this isn't a new namespace footprint; verified oadp-operator's e2e suite has no unfiltered pod-count assertions or namespace teardown that this would disturb — its one pod check is scoped by LabelSelector: "component=velero".)
2. set-related-image: discovers the Subscription OLM created (oc get subscription -n ${OO_INSTALL_NAMESPACE} -o jsonpath=... — operator-sdk run bundle doesn't write a SHARED_DIR marker for it the way optional-operators-subscribe does; the namespace is created fresh by this same step script if it doesn't exist, so exactly one Subscription is expected), then oc patch subscription ... RELATED_IMAGE_KUBEVIRT_DATAMOVER_CONTROLLER= (_PLUGIN for the plugin repo) via Subscription.spec.config.env, OLM's supported override mechanism: per OLM's own design doc, values set here overwrite same-named CSV env vars and survive reconciliation, unlike patching the Deployment directly. Polls the Deployment's own env value before calling oc rollout status (checking immediately after the patch is racy — can report the pre-existing rollout as already complete before OLM notices the Subscription change).
3. make TEST_VIRT=true test-e2e from the promoted test-oadp-operator image, same as before.

Also fixes a real bug in the shared optional-operators-operator-sdk-non-ci-bundle-image step: INSTALL_MODE_ARG=--install-mode="${INSTALL_MODE_ARG}" was self-referential and silently dropped OO_INSTALL_MODE for every consumer of that step. Fixed to reference ${OO_INSTALL_MODE}. Note: for oadp-operator specifically this isn't load-bearing — its CSV only declares OwnNamespace as a supported install mode, so operator-sdk's own fallback logic (pick the first supported mode when none is explicitly forced) would land on OwnNamespace regardless of the bug. It's still a real bug worth fixing (and we set OO_INSTALL_MODE: OwnNamespace explicitly regardless, so behavior here is pinned rather than incidental) — just correcting the record that it wasn't actually blocking this PR.

Why not an index

The original design (this PR's earlier revisions, and #83110) promoted an oadp-operator-index built via ci-operator's operator.bundles (no skip_building_index). Rehearsing against the real promoted images failed with BundleUnpackFailed: Bundle image pull failed. Root cause, confirmed from oadp-operator's own promotion postsubmit log: ci-operator builds the bundle as an image inside the building job's own namespace, then bakes a reference to that bundle's pullspec into the generated index. That reference is reachable only while the building job's namespace is still alive (same-job consumption, e.g. oadp-operator's own periodic e2e, works fine) — we'd promoted only the index, never the bundle, so once oadp-operator's build namespace was torn down, the baked-in bundle reference became permanently unreachable from any other job's namespace.

Fix: promote the bundle itself (precedent: quay/quay-operator uses the same skip_building_index: true pattern) and install directly from it via operator-sdk run bundle (precedent: openshift-file-integrity-operator, which already installs cross-repo from a bundle image this way, no index/catalog needed at all). Confirmed the bundle pull itself is not a concern — the failed rehearsal's CatalogSource already reached READY pulling from registry.ci.openshift.org/konveyor/... (same host, same namespace, same cluster pull secret the bundle now uses).

OLMv1 compatibility

Unaffected by the above — this PR doesn't produce an FBC catalog either. Same underlying gap as before: the bundle is legacy registry+v1 format, and oadp-operator's CSV hasn't yet declared AllNamespaces install mode, both tracked separately for OLMv1 adoption.

Testing

make ci-operator-config/make jobs pass cleanly for all 6 changed configs. Generated job diff confirms the oadp-operator postsubmit's promotion target changed from ci-index to oadp-operator-bundle (and the standalone ci-index presubmit is now ci-bundle-oadp-operator-bundle) — the kdm-side job files are unchanged since multi-stage step graphs (pre/post/workflow) resolve from config at ci-operator runtime, not the static Prow job YAML. coderabbit review --agent against upstream/main reports 0 findings.

Test plan

• make ci-operator-config / make jobs pass for all 6 changed configs.
• Generated job diff confirms the promotion target rename (ci-index → oadp-operator-bundle) took effect correctly.
• CodeRabbit review: 0 findings.
• /pj-rehearse against the new bundle-direct install path — no BundleUnpackFailed, CSV reaches Succeeded, set-related-image finds exactly one Subscription and its override actually applies (not yet exercised by any prior rehearsal — the previous run died at bundle-unpack, before reaching this step).
• First real run against an actual kdm-controller/kdm-plugin PR on each branch, once this merges and the new jobs go live.